今天想先跳出來寫一下在整個工具系統開發過程中常被沒有實際參與專案開發的人員忽略、但實際上卻極不可或缺的測試驗證環節。在前幾天的文章中有提到，這套系統在設計過程中，其實一直都在反覆測試和調整。尤其是逐字稿產出和後續的評量報告產出，這兩個階段都不是把Prompt寫好之後，直接丟進系統跑就可以了，而是需要先透過多次POC (Proof of Concept)確認結果是不是符合預期。

一開始系統還沒有完整建立的時候，我其實做了很多非常土法煉鋼的測試。

例如我要測試逐字稿的產出，就把已經寫好的逐字稿Prompt，加上一場實際收集到的會議錄音，直接丟進Gemini 的Chat裡，讓它產出結果，再一份一份回頭檢查產出品質。我會用英文、中文、日文等不同語言的會議素材，去測試同一套Prompt在不同語言下的表現是否穩定，也會檢查它是不是按照我們要求的格式輸出。

但做了一陣子之後，發現即使使用的是同一個Gemini model，產出的結果還是時常有差異。格式可能不完全一致，逐字稿品質也可能有所落差。這時候逐漸意識到，如果真要確保系統產出的品質穩定，我們需要更精細的測試方式，不能只是一直把素材丟進Chat裡。我們可能無法做到100%毫不出錯的產出，畢竟也還有許多外在變因，像是每個業務提供的會議錄音品質不一，但至少希望產出控制在一定的穩定範圍。

後來，我們開始嘗試使用Google AI Studio進行測試，因為它可以讓我們對模型和相關參數做更細緻的設定，也比較適合進行這種需要反覆控制變因、比較不同結果的測試。

我們也不是一開始就決定一定要用Gemini。過程中其實也比較過 ChatGPT、Claude 等不同模型，最後選擇 Gemini，一方面是考量它在多語言處理上的表現，另一方面也是因為公司本身主要使用 Google 的生態系統。

這個選擇並不是一次測試就決定的，而是在不同模型、不同設定、不同語言素材之間反覆比較，也衡量過實際的各樣成本之後，逐漸形成的結論。過程完全像是在做反覆的實驗，必須盡可能控制變因，才能釐清到底是哪個設定造成結果的差異，進而知道該如何調整。也有一些時候，我們會發現最直接的調整方式就是再次回到源頭，去修整一開始寫的prompt。

不過，即使最終好不容易在Google AI Studio裡測試到一個看起來很穩定的結果，也不代表部署進系統之後就一定一樣。

在實際的系統環境裡，錄音來源、檔案、工作流程甚至其他系統設定，都可能讓最後的結果產生落差。進入正式的環境之後，又需要另一階段的測試調校。但這並不是說我們前期在Gemini Chat、Google AI Studio裡做的POC是做白工；當時做的測試其實讓我們在相對單純的情況下，先針對prompt本身做了很好的測試、修正和確認。待進入系統之後，我們對prompt的品質已有信心，接下來就可以更聚焦在系統工作流程、檔案處理機制等調整和優化。

整個開發過程中，測試驗證環節確實偶爾會被人質疑真的有必要花這麼多時間嗎？的確，測試驗證所花費的心力和時間往往是一開始最容易被低估的，但隨著進度的開展、系統越長越大設計越複雜，我越感受到反覆測試驗證的必要性。這不僅僅是要證明「系統可以做」，而是要找出在什麼條件組合設定下，它才能穩定產出我們需要的東西。